
        Nous avons modélisé le comportement d'un thread, et pour cela, nous avons estimé qu'en mémoire, un thread devait obligatoirement avoir un identifiant, 
  une variable caractéristique de son état (SLEEPING, READY...), une priorité (ce qui permet de faire passer un thread plutôt qu'un autre). 
	D'un point de vue plus technique, il faut aussi un pointeur vers un thread prêt à prendre la suite quand il aura fini de tourner, 
	ainsi qu'un contexte,  et un pointeur vers un -éventuel- autre thread dans la liste chaînée, puis la valeur de retour du thread.
	Nous avons donc représenté nos threads de la manière suivante :\\ 

        \begin{lstlisting}
	struct thread{
		pid_t id;
		ucontext_t uc;
		struct thread *next;
		struct thread *joiner;
		status st;
		unsigned char priority;
		void *retval;
	};
        \end{lstlisting}
	~\\
        Comme vous pouvez le constater, les threads qui seront en attente seront chaînés entre eux, ce qui apparaît être la solution la plus efficace sachant que l'on sera en permanence amenés à supprimer et ajouter des éléments. Nous avons donc implémenté un module de gestion des listes, relativement classique. En effet, on extrait en tête, et on ajoute un thread de manière triée en fonction de la priorité. En voici les fonctions :\\

        \begin{lstlisting}
	struct queue_thread {
		thread_t first;
		thread_t last;
	};

	struct queue_thread* new_queue_thread ();
	thread_t get_first_thread (const struct queue_thread *q);
	thread_t extract_first_thread (struct queue_thread *q);
	void add_thread (struct queue_thread *q, thread_t t);
	void print_queue (struct queue_thread *qt);
        \end{lstlisting}


        Nous avons implémenté une module de test, le comportement semble correct, comme en témoigne la figure ~\ref{list} :     

        \begin{center}
            \begin{figure}[h]
               \includegraphics[scale=0.3]{pictures/test_list2.png}
               \caption{\label{list} tests du module list.h}
            \end{figure}    
        \end{center}

